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Abstract. We present a novel algorithm for interface generation of soft- 
ware components. Given a component, our algorithm uses learning tech- 
niques to compute a permissive interface representing legal usage of the 
component. Unlike our previous work, this algorithm does not require 
knowledge about the component’s environment. Furthermore, in con- 
trast to other related approaches, our algorithm computes permissive in- 
terfaces even in the presence of non-determinism in the component. Our 
algorithm is implemented in the JavaPathfinder model checking frame- 
work for UML statechart components. We have also added support for 
automated assume-guarantee style compositional verification in JavaP- 
athfinder, using component interfaces. We report on the application of 
the presented approach to the generation of interfaces for flight software 
components. 


1 Introduction 

Component interfaces are a central concept in component-based software engi- 
neering. Although in current practice, interfaces typically describe the services 
that a component provides and requires at a purely syntactic level, the need 
has been identified for interfaces that document richer aspects of component 
behavior. Such extended interfaces are usually not provided, which makes their 
automatic generation an area of active research [7,7,7] . 

This paper addresses the automatic generation of interfaces that describe le- 
gal sequences of component calls. Such interfaces can serve as a documentation 
aid to application programmers, but can also be used by verification tools in 
checking that components are invoked correctly within a system. In fact, com- 
ponent interfaces are key for modular program analysis. They reduce the task of 
verifying a system consisting of a component and a client, to the more tractable 
task of verifying that the client satisfies the component’s interface. 

In previous work [?,?,?], we presented a framework based on learning, to per- 
form automated assume-guarantee model checking of safety properties. To check 
that a system consisting of components Mi and M<i satisfies a safety property 
P, the framework automatically builds and refines assumptions A for one of the 
components, for example Mi, to satisfy P, which it then tries to discharge on 
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the other component, M 2 . Although assumptions A essentially constitute inter- 
faces for component Mi, their generation relies on knowledge of component M 2 . 
Moreover, the focus of the framework was to compute assumptions that would 
allow to prove or disprove the property in the system, rather than assumptions 
that precisely document the behavior of a component. 

The algorithm presented here for interface generation is also based on learn- 
ing. However, in contrast to our work discussed above, it concentrates on the 
creation of precise component interfaces, irrespective of the component clients. 
By precise, we mean safe and permissive , as defined in [?] . An interface is safe if it 
accepts no illegal sequence of calls to the component. An interface is permissive if 
it includes all the legal sequences of calls to the component. Moreover, in [?], we 
presented an algorithm for generating what we call weakest assumptions in the 
context of Labeled Transition Systems. Weakest assumptions essentially consti- 
tute precise component interfaces. The difference of the current algorithm is that 
it is iterative, meaning that it can return partial results. Moreover, our experi- 
ence has been that the learning-based approach is more efficient for components 
that have relatively small interfaces. 

Henzinger et al. also target the generation of safe and permissive interfaces 
in [?]. Unlike our framework, their work based on abstraction techniques and 
it is only applicable to components that are visibly deterministic. The latter 
requires that the behavior of the component be deterministic with respect to 
the methods / actions in its communication interface (we will henceforth call the 
communication interface of a component its alphabet in order to avoid confusion 
with interface in this context). In the applications that we have been dealing 
with, this requirement proved too restrictive. For example, we often need to 
generate interfaces that focus on specific aspects of the component behavior, and 
that therefore include only a subset of the component’s alphabet. Components 
that are visibly deterministic with respect to their full alphabet, typically lose 
this property when a subset of that alphabet is considered. Finally, Alur et al. 
also use learning to synthesize interface specifications for Java Classes. However, 
their approach is heuristic-based, meaning that they do not always obtain precise 
interfaces. 

We have implemented our algorithms in the JavaPathfinder (JPF) model 
checking framework for UML statechart components [?]. We have also added 
support for automated assume-guarantee style compositional verification in JPF, 
using component interfaces. JPF is an open source model checker for Java pro- 
grams which, until now, provided no support for compositional verification. This 
work, which is included in a new extension (namely CV ), adds the following 
features to JPF: 1) support for verification of safety properties expressed as 
finite state automata; 2) support for learning- based interface generation; and 
3) support for assume-guarantee reasoning, where assumptions and guarantees 
are both expressed as finite-state automata. We finally report on the applica- 
tion of the presented approach to the generation of interfaces for flight software 
components. 

The contributions of this work can be summarized as follows: 
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1. A novel algorithm for automated generation of precise component interfaces, 
also applicable to components that are not visibly deterministic 

2. Implementation of our algorithm in the JPF open source model checker. 
In addition to interface generation, we have provided support for assume- 
guarantee reasoning in JPF, where assumptions and guarantees are both 
expressed as finite-state automata. 

3. Case studies in the context of NASA applications that demonstrate the use 
of our algorithm in practice. 

Related Work The work closest to ours was discussed above. Several other ap- 
proaches to automatic generation of component interfaces have been proposed 
in the literature. For example, Whaley et al. [] use a combination of static and 
dynamic analyses to generate interfaces for Java components. Tkachuk et. al [] 
use static analysis to obtain component abstractions, used as environments dur- 
ing modular analysis. Some approaches are based on extracting interfaces from 
sample execution traces [?,?]. All these techniques generate approximate inter- 
faces, as opposed to our work that aims at producing interfaces that provide 
correctness guarantees. Interface generation is related to compositional verifi- 
cation. In particular, assume-guarantee reasoning is a compositional approach 
that uses assumptions when reasoning about components in isolation [?,?,?,?]. 
Component interfaces can be used as assumptions in this context. 

2 Background 

We model software components using labeled finite state transition systems 
(LTSs), where transitions are labeled with component actions. 

Let Act be the universal set of observable actions and let r denote a local 
action unobservable to a component’s environment. Let n denote a special error 
state , which models safety violations in the associated transition system; i r has 
no outgoing transitions. 


LTSs An LTS M is a four-tuple (Q, ckM, <5, go) where: Q is a finite non-empty 
set of states; aM C Act is a set of observable actions called the alphabet of M; 
5 C Q x (aM U {t}) x Q is a transition relation; and go £ Q is the initial state. 

Let M = (Q,aM, <5, q Q ) and M* = (Q r ,aM f ,8 f M transits into M f with 

action a, denoted M M', if (go,a, g^) € ^ and either Q = Q ' , aM = aM f , 
and 5 = S' for q f 0 ^ n. 

An LTS M = (Q, aM, <5, g 0 ) is non- deterministic if it contains r-transitions 
or if there exists (g, a, q f ), (g, a, q") £ S such that g' ^ q" . Otherwise, M is 
deterministic. 

Traces A trace t of an LTS M is a finite sequence of observable actions that 
label the transitions that M can perform starting at its initial state, ignoring 
the r-transitions. For E C Act , we use t \ 1 7 to denote the trace obtained 
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by removing from t all occurrences of actions a £ E. For a set of traces T, 
T T 27 = {t\3t f e T.t' T E = t}. 


Parallel Composition Parallel composition “||” is a commutative and as- 
sociative operator such that: given LTSs Mi = J 1 , an d M 2 = 

(QVM^ 2 ,^ 2 ), Mi || M2 ig an LTg M = 5,q 0 ), where Q = Q 1 x Q 2 , 

go = = <*Mi U a ^ 2 5 and J is defined as follows (the symmetric 

version also applies): (1) M x || M 2 || M 2 if M 1 M[ and a ^ aM 2 , 

and (2) Mi || M 2 M' || M' if Mi M{, M 2 M^, and a ^ r. 

3 Interface Generation 

In this section we define safe and permissive interfaces for software components 
and we describe our approach to synthesizing such interfaces autmatically. 

3.1 Safe and Permissive Interfaces 

Let M be a software component. For simplicity of presentation, we will first 
assume that M includes an error state that expresses the undesired behavior of 
M (for example, some asertion violations). This same case is considered in the 
related work of Alur et al. \\ and Henzinger et al. []. Later in this section we 
will discuss the more general case where the component property is given as a 
separate (safety) automaton. 

Let £ C aM denote the communication alphabet of component M, i.e., the 
set of actions through which M communicates with its environment. Our goal 
is to compute M’s precise interface as a finite state automaton A over E. As 
mentioned, we need to make sure that A is both safe and permissive , as defined 
formally below. 

Let us first define the legal and illegal languages of component M. A word 
t £ aM * is illegal if it corresponds to some trace of M that leads to error state 
7 r; otherwise, the word is legal Then Ci ega i(M) denotes the set of legal words of 
M and Cm ega i(M) denotes the set of illegal words of M. Note that Ci ega i(M) 
and Cm ega i(M) are complementary. Furthermore, note that, while illegal words 
correspond to actual traces in the component, legal words may also represent 
behavior that is never executed by the component (and hence could never lead 
to violations). 

Definition 1. A is a safe interface iff Ci ega i(A) fl Cm ega i(M) f E = 0. 

In other words, an interface is safe if it accepts no illegal words of M. 
Definition 2. A is a permissive interface iff Ci ega i(M) | E C Ci ega i(A). 

In other words, an interface is permissive if it accepts all legal words of M. 
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Fig. 1. Learning interface specifications with L* 


3.2 Learning Interface Specifications with L* 

Our approach for learning interface specifications is illustrated in Figure 1. We 
use an off-the-shelf learning algorithm, namely L* [?], to iteratively compute the 
interface specification A for M that is both safe and permissive. L* learns an 
unknown language (over a given alphabet) and produces a deterministic finite 
state automaton that accepts it; the learning process is iterative and it uses a 
teacher that provides answers to queries and counterexamples to conjectures (for 
more details on L* see []). In our framework, the problem of answering queries 
and counterexamples is reduced to reachability problems, solved by a model 
checker. 


Queries L* is first used to repeatedly query M to check whether or not, in the 
context of strings w, M violates the property. This is equivalent with checking 
if an error state i r is reachable in lts(w)\\M. Here lts(w) denotes an LTS over 
E that accepts only string w. The results of the queries are used by L* to first 
make a “conjecture”, i.e. it builds an automaton A that accepts all the strings 
for the positive queries (the case error unreachable), and does not accept the 
strings for the negative queries (the case error reachable). 

The conjectured automaton A is then checked to make sure it is both safe 
and permissive. This is done with the help of a teacher that implements two 
oracles as described below. 
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Oracle 1 checks if A is safe by checking whether 7 r is reachable in A || M. If it 
is, then it means that A is un-safe. The resulting counterexample t, projected on 
the interface alphabet 27, is returned to L* to refine its conjecture. If the error 
state is un- reachable, then it means A is safe and we proceed to Oracle 2. 


Oracle 2 checks if safe interface A is also permissive, i.e. we want to check 
that Ci e g a i(M) | 27 C jCi e g a i(A). This amounts to making sure that there are no 
words w £ 27* such that w £ Ci ega i(M) j 27 Pi Cui ega i(A). This is equivalent to 
w £ £iiiegal{A) and Vt £ aM such that w = 1 1 27, t £ £/ eff a/(7kf). 

We search for such words using a special reachability procedure performed 
on A n || Me (see pseudo-code in Figure 2). Here A n denotes the completion 
of A with an error state, i.e. we complete each state with outgoing transitions 
to 7 r, such that each state has outgoing transitions labeled with every action in 
27. Similarly, Me denotes the completion of M with a special sink state. We 
need these constructions to reason about traces in Cui ega i(A) and Ci ega i{M ), 
respectively. Note that C, niegai (^) — £uiegai[ j ^- 7T ') and C, i^gai (7W) — ^legai^-^c^)' 
Note that, for Oracle 2, since both A n and Me contain error states, we need to 
distinguish between the two in A n || Me (this was not necessary for queries and 
Oracle 1). 

Given the above constructions, checking permissiveness reduces to checking 
reachability of states of the form: ( 7 r, ok ), were 7 r is an error state coming from A n 
and ok denotes a non-error state in Me- If such a combined state is found, then 
the trace t leading to it may indicate that A is not permissive, since w = t f 27 
leads to an error state in A n but it is legal in Me (and hence in M). However, 
due to non-determinism in M (and hence in Me), it may be the case that on 
another path, t does lead to the error state. Even if this is not the case, there 
may exist other traces t' such that w = t f | 27 and t f leads to an error in Me 
on a different path (see Figure 3). We check both these cases by performing a 
query on 1 1 27. Note that we do not stop the state space exploration in JPF, but 
rather, we take trace t that is returned, and we check if, in the context of £ | 27, 
M violates its properties. 

If the query returns true, then it means the interface is not permissive, and 
therefore t T 27 is returned to L* for refinement, and the learning process con- 
tinues with more queries and eventually with a new conjecture. 

If the query returns false, then t does not correspond to a real counterexam- 
ple. Model checking therefore ignores this state; it backtracks, and then continues 
its state space exploration. If no traces that satisfy the condition above exist, 
then indeed the conjectured automaton is also the most permissive interface, 
and therefore it is output to the user. 

We note that every query is stored in the L* memoized table, so the result of 
the query on the same trace t f 27 later (when A is the same) will be obtained 
directly (and faster) from the table. 


Example: dealing with observable non-determinism We use the Exam- 
ple in Figure 3 to illustrate the reason for the extra query to deal with non- 
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Oracle 2 

input: safe interface A ; 

begin 

(1) Model-check A n \\Mc : 

(2) if (7T, ok) is reachable by trace t then 

(3) if 7T is not reachable in lts(t | P)||M then 

(4) return t f P to L*; 

(5) else 

(6) backtrack; 

(7) output: safe and permissive interface A; 
end. 


Fig. 2. Oracle 2 
State space of A n || Me 



Fig. 3. Example for Oracle 2: dealing with non-determinism 


determinism in the component behavior. Assume that model checking A n \\Mc 
finds a state of the form (n, ok) that is reachable by trace t. 

Assume also that there is another trace t f such that t | E = t f ] we say 
that M (and Me) is observable non- deterministic (to keep a similar terminology 
to the one introduced in []). 

Furthermore, assume that t f leads to (7 r, 7 r). In this case, A is permissive with 
respect to w\ therefore, the model-checker is instructed to backtrack and then to 
continue the search for other states of the form (7 r, ok) (that may indicate that 
A is not permissive enough). 


Properties as safety automata Assume now that M does not have error 
states, and we want to generate an interface specification for ensuring a property 
P, given as a (deterministic) safety automaton, encoding all the desired behaviors 
of the component. Conversely, P n encodes all the un-desired behaviors of the 
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component. The procedure described above will be exactly applicable to this 
case as well, if we treat M\\P n as M above. 

3.3 Correctness and Termination 

We argue here the correctness and termination of our approach. To argue cor- 
rectness, we first show that Oracle 1 guarantees a safe interface while Oracle 2 
guarantees a permissive interface. 

Proposition 1. n is un-reachable in A \\ M iff Ci ega i{A) n Hui ega i{M) f E = 0. 

Proof. “If:” By contradiction. Assume Ci ega i{A) PI Ciii ega i(M) f E ^ 0. Then , 
3t £ aM* such that t | E £ £(A) and t leads to error in M. Then t is also 
leading to an error in A\\M which is a contradiction, q.e.d. 

“Only If:” 

Proposition 2. (tt, ok) is un-reachable inA n \\Mc iff Ci ega i(M) f E C Ci ega i(A ) 

Proof. “If:” By contradiction. Assume Ci ega i(M) f E C Ci ega i(A) does not hold. 
Then 3t £ aM * such that t £ Ci ega i (M) and 1 f E £ Cui eg ai (-4) • Then t is also 
leading to (n, ok) in A^Mq which is a contradiction, q.e.d. 

“Only If:” 

Theorem 1. Given component finite state M (that may include error states ), 
the algorithm implemented by our approach terminates and it returns a safe and 
permissive interface A. 

Proof. Correctness follows from the two propositions above. Termination follows 
from the correctness of L * which is guaranteed that, if it keeps receiving coun- 
terexamples, it will eventually terminate. 

We note here that the approach of Henzinger et al. \\ can only handle com- 
ponents that are observable deterministic. However, we believe that this is very 
limited in practice, since even if the component itself is deterministic, consider- 
ing only its interface behavior (and abstracting away its internal behavior) leads 
to non- determinism. 

Furthermore, the approach of Alur et al. ?? proposes to generate safe inter- 
face specifications for Java components, that are made finite state using predicate 
abstraction techniques (and therefore they can be non-deterministic) . However 
the approach does not guarantee that the interface is also permissive, since it 
only uses heuristics to implement what it amounts to Oracle 2 (which is called 
“superset query” in []). That work argues that Oracle 2 can not be implemented 
efficiently, since it involves determinization of component M. We note that in 
our approach we avoid the expensive determinization step by performing the 
extra query on the traces that lead to (n, ok). While the worst case complexity 
of our approach can not be avoided, in practice we noticed that Oracle 2 is not 
called very often. 

How does it compare with our old approach at ASE? It also involved deter- 
minization. 
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4 Compositional verification in JPF 

4.1 Java PathFinder 

Java PathFinder (JPF) [?] is a verification framework developed by the RSE 
group at NASA Ames. It has been started as an explicit state model checker for 
Java byte-code. The focus of JPF is on finding bugs, such as concurrency related 
bugs (deadlocks, races, missed signals etc.), runtime related bugs (e.g. unhan- 
dled exceptions), etc. JPF can also check for violations of user-specified assertions 
that encode application specific requirements. JPF uses a variety of scalability 
enhancing mechanisms, such as user extensible state abstraction and matching, 
on-the-fly partial order reduction, configurable search strategies, and user defin- 
able heuristics (searches, choice generators). JPF has been open sourced since 
04/2005 under NOS A 1.3 license and it is available for download from javap- 
athfinder . sourceforge. net . 


4.2 JPF’s UML Statechart Extension 

To address the needs for model analysis of flight software, JPF has recently been 
extended with a state-chart modeling and analysis capability that allows Java 
modeling of UML state machines []. Many UML development systems can pro- 
duce code from diagrams, but this code is usually aimed at production systems, 
and is not suitable for software model checkers. The approach taken in JPF 
(Figure 4) is based on a specific translation scheme from UML state charts into 
Java code that (a) is highly readable, (b) shows close correspondence between 
diagram and program, (c) provides a 1:1 mapping between model and program 
states, and (d) imposes no restrictions about aspects and actions that can be 
modeled. 

The JPF statechart extension is specialized to handle the obtained Java 
models more efficiently than random Java code. These Java models can be run 
in isolation, which corresponds to running them in the context of an external 
environment that may provide any input event at any stage (we will call this the 
universal environment). Alternatively, a guidance script may be provided by the 
user, which represents the input event sequences that can be provided by the 
external environment. 

We have used the JPF statechart extension to implement our interface syn- 
thesis algorithms for components expressed in the JPF statechart framework. In 
the context of this work, we do not attempt to perform compositional reason- 
ing for UML statecharts. The reason is that statechart composition semantics is 
obfuscated and setting up compositional reasoning for statecharts is a challenge 
even at a purely theoretical level. Rather, we use UML statecharts, as supported 
by JPF, to represent finite state components with Labeled Transition System 
semantics. Therefore composition of components comes down to LTS composi- 
tion, as described in Section ??. The interfaces that we generate are expressed 
as LTSs in the FSP notation [] . 
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Fig. 4. Example illustrating JPF’s UML extension 


4.3 Assume- guarantee Reasoning in JPF 

Model checking using assumptions and properties has been implemented using 
JPF listeners. A JPF listener is an extension mechanism that enables client 
code to be informed of certain events that occur while JPF performs its search. 
Listeners can also interact with JPF, for example, a property listener will in- 
form JPF of the fact that a property has failed, through a condition that it 
provides in its checkQ method. Both assumptions and properties are imple- 
mented with the gov . nasa . jpf . cv . SCSaf etyListener class, which extends the 
gov. nasa.jpf.PropertyListener Adapter class, provided by JPF to ease property 
creation. On creation, a SCSaf etyListener is associated with a finite state au- 
tomaton (gov .nasa . jpf . cv . SCSaf etyAutomat on) P, which expresses the prop- 
erty or assumption to be used during model checking. Note that the state of a 
listener is not included in the state that JPF explores / stores during model 
checking. However, the state of the automaton P needs to be part of the state 
space for correct state-space exploration and backtracking. *** We perform this 
by adding a static integer field AssumptionState of class CVState for the CV 
extension. It can be set as follows: 

MJIEnv env = ti.getEnvO; 

env. setStaticIntField ("gov. nasa. jpf . cv. CVState" , "AssumptionState" , 
P . getCurrentState 0 ) ; 

An SCSaf etyListener listens for and reacts to the following events: 

— instructionExecuted: signals the fact that an instruction was executed by 

JPF. The reaction of the listener is to invoke method advance (...) on 
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the automaton P. Advancing the automaton corresponds to making a state 
transition, if the instruction that was executed corresponds to an action 
in the alphabet of the automaton. If a transition on an alphabet action is 
undefined from the current state, this is an illegal transition (corresponds to 
a transition to the error state). For properties, this means that an error has 
occurred, so the result returned by the checkQ method of the listener is set 
to false. 

— choiceGenerat or Advanced: signals the fact that the next statechart action 
is selected for execution. The reaction of the listener is to enquire with 
P whether this action would make it transition to the error state if it 
were to be executed (this does not change the state of P since the tran- 
sition is not really executed yet). Reaching an error state in an assump- 
tions means that the current path explored is not a valid path under this 
assumption and must therefore be ignored. The listener performs this as fol- 
lows: vm.getSystemStateO . set Ignored (true), which requests for JPF to 
backtrack. 

- st at eBackt racked: when the model checker backtracks, then the automaton 
must backtrack accordingly. We perform this by getting the JPF path to the 
current model state after backtracking, and replay the path on the automa- 
ton, to ensure that the two are in synch. 

Could we not do get Staticlnt Field instead??? 

For example, in order to check some property described as an automaton pro- 
vided in some file Foo, we need to include the following arguments when running 
JPF’s main class gov.nasa. jpf . JPF: 

+jpf . listener= . cv . SCSaf etyListener 
+saf etyListenerl .property= Foo 

The first argument informs JPF that an SCSaf etyListener will need to be 
notified of specific events, and the second one provides details for the listener, 
i.e., its unique id is “1”, it is of type property (as opposed to assumption), and 
the automaton associated with it is provided in file Foo (this may also include 
the full path to Foo). 


4.4 Interface Generation and Discharge 

Interface generation in JPF can be performed by invoking the main class gov . nasa . jpf . tools . cv . ScRunCV. 

Argument +assumption.alphabet=<actions> is used to define the alphabet of 

the interface to be generated, in terms of method names. Argument +as sumption . output File=<f ile 

name> defines a file in which the generated interface is output. This allows for a 

generated interface to be used for subsequent reasoning, either as an assumption, 

or as a property. The format currently used for expressing the interface is the 

FSP language [|. 

The main method of gov . nasa . jpf . tools . cv . ScRunCV creates an instance 
of class gov .nasa. jpf .tools . cv . SETLearner to carry out the learning of the in- 
terface, with an associated instance of gov .nasa. jpf .tools . cv . SCModularTeacher 
to serve as the teacher. Our learning algorithm implementation uses JPF to 
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public boolean query (Vector sequence) throws SETException { 

Boolean recalled = memoized_ .getResult (sequence) ; 
if (recalled != null) { 

return (! recalled. booleanValueO ) ; 

> else { 

// play the query as an assumption 
System. out .print In ("\n New query: " + sequence); 
SCSafetyListener assumption = new SCSaf et y Listener ( 
new SCSaf ety Automat on 

(true, sequence, alphabet., "Query", modulel.)); 

JPF jpf = create JPFInstance (assumption, property, module 1 _) ; 
jpf -run() ; 

boolean violating = jpf . f oundErrorsO ; 
memoized. . setResult (sequence , violating) ; 
return ( ! violating) ; 

> 

> 


Fig. 5. Answering queries in SCModularTeacher 


perform the model checking steps described in Section ??. JPF model checks 
individual components in the context of the universal environment. Listeners 
are added as necessary to reflect the work of the Teacher, which consists of an- 
swering Queries, and implementing Oracle 1 and Oracle 2 in order to answer 
conjectures, as described in more detail below. 


Queries and Oracle 1 . Queries and Oracle 1 are performed in a similar fash- 
ion because they are concerned with checking whether error states are reachable 
in the component, in the context of a particular sequence (for queries) or finite 
state automaton (for Oraclel). As illustrated in Figure 5, to respond to a query, 
a listener instance assumption is created with an associated automaton that re- 
flects the particular sequence that is being queried. The automaton is considered 
as an assumption. JPF is then invoked, together with the assumption listener. 
If JPF returns errors, the answer to the query is false, otherwise the answer is 
true. Oracle 1 works in a similar fashion, with the difference that it also returns 
a counterexample. 


Oracle 2. Oracle 2 checks for permissiveness of a computed interface. It needs 
to work on the completed component, as described in Section ??. This is a man- 
ual step that we intend to automate in the future. It similarly invokes JPF, 
but performs the search in the context of a specialized type of listener, the 
gov.nasa. jpf . cv. SCConf ormanceListener. Its aim is to detect the reachabil- 
ity of a ( ok , error) combination of states in the component and interface where 
the component is in a non-error state, while the interface is in an error state. 
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The gov . nasa . j pf . cv . SCConf ormanceLi stener listens for and reacts to the 
following events: 

— executelnst ruction: When the instruction about to be executed by JPF is 
an assertion violation, then it means that the component has entered an 
error state. Since such states are not targeted by the listener, it performs 

ti . skiplnst ruction () ; followed by vm.getSy stemS t ate () . set Ignored (true) 

The first command ensures that the exception is not processed by JPF, for 
efficiency. The second asks JPF to backtrack since this path cannot lead 
to the targeted combination of states. Note that choiceGenerat or Advanced 
(which gov. nasa. jpf . cv. SCSaf etyListener listens to), does not monitor 
exceptions. 

— instructionExecuted: reacts similarly to gov . nasa. jpf . cv . SCSaf etyListener. 

When the automaton associated with the listener moves to an error state, 
the result returned by the checkQ method of the listener is set to false. This 

is because the component is in a legal state (illegal states are never reached 
since the listener advises JPF to backtrack when it reacts to executelnst ruc- 
tion events), while the interface is in an error state. 

— stateBacktracked: reacts similarly to gov . nasa . jpf . cv . SCSaf etyListener. 

As described in Section ??, when an (ofc, error) state is detected by the model 
checker, if the counterexample leading to this state is queried, so that if it is not 
a real counterexample, the model checker will backtrack. Since a query involved 
calling the model checker, this would involve nested model checker calls. To avoid 
such nesting, our implementation exploits a memoized table that is used by the 
learner to store results of previous queries. Oracle 2 checks for the reachability 
of (o/c, error ) states in a loop. Whenever a counterexample is obtained by the 
model checker, then Oracle2 invokes a query on it. Each query stores its result 
in the memoized table. 

Whenever a real counterexample is obtained, then Oracle 2 exits the loop 
and reports the result to the learner. When a counterexample is spurious, then 
another iteration of the loop is entered. In this iteration, we wish to ensure 
that the model checker will not report the same spurious counterexample. We 
achieve this as follows. When a gov. nasa. jpf . cv. SCSaf etyAutomat on is asked 
to advance in the context of a gov. nasa. jpf .cv. SCConf ormanceLi stener, if 
the automaton reaches an error state, it will get the path to this state from 
JPF. It will then check the memoized table to see if there is a result for the 
corresponding sequence stored there. If there is, and the result is true, then it 
means that this is a spurious counterexample, and it notifies JPF to backtrack. 

Therefore, we have implemented the nested model checking calls by consecutive 
calls to the model checker, where the information of spurious counterexamples 
is shared through the memoized table. 

Interface discharge. For compositional reasoning, one needs to also discharge 
the generated interface on the component environment. This can be performed by 
model checking the environment in the presence of a gov . nasa . jpf . cv . SCSaf etyListener 
using the interface as a property. 



14 


5 Experimental results 



Fig. 6. Model of the Ascent and Earth Orbit flight phases of a spacecraft 


In order to evaluate our implementation, we used a state-chart model of the 
Ascent and EarthOrbit flight phases of a space-craft (see Figure 6). The JAVA 
model is available with the JPF distribution under example s/jpfESAS. The 
UML statechart diagrams corresponding to the model are included in examples/ jpfES AS .doc. 

The model was created and used to demonstrate the features of the JPF UML 
statechart extension to our mission customers. Several properties were analyzed 
on the model, and JPF returned violations for some of these properties. When the 
counterexamples obtained were analyzed, it was clear that some of the violations 
were spurious. The violations were related to the following properties: 

— An event IsamRendezvous , which represents a docking maneuver with an- 
other spacecraft, fails if the LAS (launch abort system) is still attached to 
the spacecraft. 

— Event tliBurn (trans-lunar interface burn takes spacecraft out of the earth 
orbit and gets it into transition to the moon) can only be invoked if EDS 
(Earth Departure Stage) rocket is available. 

These violations were due to the fact that the universal environment was too 
general. The models had been created under the assumption that the use of the 
model respects some implicit flight rules. We decided to use our interface genera- 
tion techniques to formalize the flight rules. More specifically, for each property, 
we generated a safe and permissive interface to eliminate its corresponding vio- 
lations. To do this, we added a listener that eliminated all assertion violations 
that were not related to the targeted property, through the following arguments: 
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+jpf . listener= . tools . ChoiceTr acker : . cv . Assert ionFilteringListener 
+assertionFilter . include=<methoduiame> 

These arguments specify that all assertion violations that occur outside the 
particular methodmame> will be ignored. 


Interface 1: Interlace 2: 



Fig. 7. Generated interface specifications encode assumptions about component envi- 
ronments 


The generated interface specifications are illustrated in Figure 7. The first 
one expresses the fact that the IsamRendezvous maneuvers cannot start before 
the las module of the spacecraft has jettisoned. According to the second one, 
it does not make sense to perform tliBum prior to performing IsamRendezvous . 
These interfaces were inspected by the developer of the model that confirmed 
that they encode actual flight rules. Interface generation can therefore be used by 
developers to help them in the expression of the assumptions that their models 
encode. 

6 Conclusions 

We have proposed an algorithm for automatically synthesizing behavioral in- 
terface specifications for finite state software components. Our algorithm is the 
first to compute precise interfaces even in the presence of non-determinism in 
the visible behavior of a component. We have implemented our approach in 
the JavaPathfinder model checking framework for UML statechart components, 
and have obtained promising results from its application to several systems. The 
source code of our implementation and the examples to which it has been applied 
are available through javapathfinder.sourceforge.net. 

In the future, we plan to investigate interface generation for methods with 
parameters. We have made some initial experiments using JPF’s symbolic execu- 
tion extension to generate values for parameters with infinite domains, and used 
these values to define finite interface alphabets related to their corresponding 
methods. We wish to pursue this direction further, and also plan to general- 
ize our results for generic Java components. For generic Java components that 
may be infinite, we will combine our approach with techniques such as predicate 
abstraction. 



